The evolution of Web content has evolved from pure text content, to images (static and animated), audio and video. For the most part, multimedia has been a great addition to any website, as it provides an option for richer content and visual design. Although the Web provides support for audio and video (i.e., movies, streaming real-time feedback or animation), it doesn't necessarily represent the best medium to replicate these formats compared to other platforms, such as a CD or DVD player. The reason the Web has problems supporting audio and video is that the file size of the multimedia components requires a great amount of time to download or stream. By publishing files for a complete download, the viewer needs to wait for the file to download in its entirety before it displays. The other method, streaming, allows the contents to display and play when the first segment is made available, while in the background the rest of the file is being downloaded. Even with these methods for large file size video, many considerations need to be taken into account when including video files on a Web site.
Animations, both in 2D and 3D, are considered to be a type of video. Any 2D animation file size is considerably small when compared to a 3D animation file. The difference in the magnitude of the file sizes is due to additional features that can be, and typically are, included as part of a 3D animation: effects (shadows, reflections, waves, etc), surfaces, textures, etc. Because of its visual benefits, 3D animation has been an asset for almost any market that requires demonstrating a product, procedure, location, or any other element of interest. In most cases, an animation is enough to provide the necessary information but in product procedures, specifically detailed-oriented procedures, such as for example, a medical device. There are two characteristics which do not make this type of animation the best solution for detail-oriented procedures: file size and lack of interactivity. The files are large and the lack of interactivity is restrictive.
In a traditional 3D animation the file size is inherent to the format. There are no solutions to work around this issue. The problem doesn't arise when the animation is distributed through CD, DVD or even viewed locally from the end-user's computer. As animations become part of a company's marketing or training solution, internet distribution is inevitable; and this is when file size becomes a problematic issue.
In addition, traditional 3D animation provides a pre-set camera angle, giving the viewer no other choice but to see the artist's interpretation of the procedure. When animations are detail-oriented, it is important for the viewer to be able to manipulate and interact with the animation. By giving complete control to the user, an animation would be more appreciated and useful if it was accessible from different angles, positions and distances.
Moving from traditional 3D animations to a format that addresses both of these issues, file size and interactivity, is the main reason that MAG10 technology is being implemented on animations designed for the Viewpoint Media Player (VMP). The file size is reduced drastically, so internet distribution is reasonable, and the user is able to interact with the animation. Unfortunately, as with any solution, there will always be new challenges to overcome. In their native format, all animations designed for the VMP have limited functionality. Basic interactivity can be added, such as for example a way for the user to stop, play or restart the animation. Ideally, for detail-oriented procedures, there should be a method for the user to be able to go to a certain point in the procedure (without viewing the entire animation), and to access the sound, or pause the procedure or continue the procedure. MAG10 technology provides a solution to implementing mid-point procedure effects.
The Internet and the World Wide Web are rapidly expanding, with businesses and individuals using their own Web pages. This has created a demand for richer Web page capabilities especially in the area of coordinated presentations and control of multimedia events, including being able to easily synchronize the execution of a plurality of multimedia events over a period of time (i.e., playing a multimedia timeline). Because not all Web page owners are sophisticated computer users, the design and programming of Web pages must remain simple. Nor should synchronizing the execution of multimedia events to a timeline defined within in a Web page require complicated or lengthy user programs. Instead implementing and controlling a Web page should be intuitive (i.e., “user-friendly”), while still providing sophisticated capabilities, such as starting and stopping animations during a sequence, shifting between sequences and defining a window for execution of a time critical event or sequence.
Web pages are composed of various multimedia elements, controls, and applets as defined by the Hypertext Markup Language (HTML) for a given Web page. Multimedia can be characterized as some combination of visual media, audio media and time. Multimedia is an open environment, with timing being the common thread across all multimedia events. Multimedia experiences, such as the movement of physical models, graphics and the playing of sound, require coordinated execution of these events. For instance, the playing of a sound bite of a door slamming should be coordinated with the animation of the door closing so the sound is heard upon the visual closing of the door, and not before or after the door closes. Even more importantly, being able to control the opening of the door, the door reaching its maximum open position and the door closing to cause the slamming sound and the abrupt stop of the movement of the door.
Providing synchronized multimedia experiences is complicated because timing control information is not inherent in the content of an HTML document. Past attempts at providing such synchronization and timing control of activities within a Web page have basically take on one of several forms, such as for example, (1) external programs and (2) lengthy, complicated scripts or programs. These solutions generally are non-user-friendly, require additional hardware resources, software resources and/or expenses, and do not provide true synchronization of multiple events to a single timeline. Additionally, other approaches have not allowed synchronization between application-specific components (e.g., graphics and audio) and host-intrinsic components (e.g., HTML elements).
External multimedia control programs, such as Director, by Macromedia, can be expensive, and do not allow the direct creation and modification of a multimedia timeline by editing the HTML code. Rather, any changes and additions to the multimedia timeline must be made using the external program itself. Furthermore, the timing mechanism of some of these external programs are based on “frames” of time rather than directly on a time scale. A frame corresponds to a duration of time during which a set of defined activities are to be performed. Frames provide a method to sequentially perform sets of activities where there is some timing relationship based on frame rates and the time required for the sets of activities within the frame to be performed. However, individual events are not specified to be executed at a particular time (e.g., at time t=10.000 seconds), rather to execute within a frame (e.g., in frame 2) which does not provide an intuitive indication of the exact time for executing the event.
Another approach has been to write lengthy code or scripts within a control loop of the computer program which evaluates the incremental time of each pass through the control loop. In which case, the control loop can tie up an entire processing thread which interferes with applications or processes, and at a minimum requires extra computer cycles. Every time the control loop is executed, a large number of statements must be evaluated to determine whether to execute the actual events. This approach is less than desirable, especially as the number of events to control the process increases. In such a case, the process becomes long and complicated, and often more complex than a typical Web author knows how to create by hand. Also, such a control loop requires a large amount of processing time to determine whether to execute an event, which is disadvantageous especially in the multimedia context where events must be synchronized to a timeline having a granularity on the order of milliseconds. Furthermore, to guarantee a desired performance, the number of events controlled by a control loop must remain small because the control loop must iterate at a rate at least as great as the fastest timing requirement. Moreover, in many implementations such as those using an HTML document, the code within the control loop is written as an interpreted script thus compounding its evaluation time in comparison with that which is implemented using a built-in service or compiled code. Therefore, as the number of events to control becomes large, the timing performance correspondingly degrades and the granularity to which events can be set to perform becomes coarser. Moreover, the timing performance varies significantly and unpredictably depending on the power, performance, and current operating load of the computer on which these scripts or sets of code are run.
A variant of this approach uses a software timer control to generate a control event on a regular basis and causing a control program to execute the process. The control program then evaluates the current time and initiates the execution of the desired multimedia event. For instance, on a Web page, the setTimeout command can be used. This HTML code variant is more desirable than that of a control loop as it decreases the amount of evaluation code required. However, using this approach, it is cumbersome at best to stop the execution of sets of active timelines, and, more importantly, there is no synchronization of two events to a single timeline. Instead, these events are independently scheduled when their respective setTimeout command is interpreted and therefore, they are not synchronized. Furthermore, when multiple events are scheduled to begin execution at the same instant of time, the order in which the events will be executed is undefined for the setTimeout command which means a Web page does not necessarily produce the same results every time it is run, either on the same or on a different computer platform. Not producing the same results on every run is a common problem in other timing control approaches as well. Furthermore, such approach have disadvantageous performance limitations because the scripts become long and complex, and the timing performance is unpredictably sensitive to the performance of the machine on which these set of code or scripts are executed.
In addition to their performance limitations, the prior approaches are directed towards basic timing control. In other words, these approaches only provide a way of initiating the execution of an activity at some defined point in the future, which is only a subset of the identified need in the computer industry for controlling multimedia experiences and applications. Lacking from these prior approaches are robust capabilities for providing true prioritization among events, the adaptation of events along the timeline, and the ability to alternate between events having different timelines.
In non-Web environments, schedulers have been provided to be able to start a process at a specified future time, e.g., a UNIX “chron” job. However, these schedulers do not provide the capabilities required for synchronizing a plurality of multimedia events along a timeline or for switching between multimedia events. For instance, the timing granularity of such schedulers is usually on the order of seconds, with no exact guaranteed starting time. Moreover, these schedulers do not accommodate single or multiple timelines with an accuracy of milliseconds for initiating actions as required for the accurate presentation of multimedia experiences. Moreover, such schedulers do not provide enhanced features for controlling the invocation of events.
Generally, animations created for a media player, such as, for example, the Viewpoint Media Player (VMP) have a limited functionality. Having limited functionality means resetting the animation, playing an animation through its entire course, lack of control, etc. Although media players such as Viewpoint Technology (VET) provide a rudimentary process to accomplish similar functionality, the lack of functionality has proven to be a drawback in an applicable project's development cycle.
A main drawback is during the initial development. Such a project requires more time in order to break down the animation. Media players assign one animation sequence per object. Thus, if there were ten objects (e.g., with respect to a medical animation the hands, tissue, instruments, etc.), there would be ten animation sequences. Each one of these sequences needs to be broken down into the number of steps required. In addition, if any maintenance was required by a project, then one would have to go back and re-create the sub-animations.
For example, Viewpoint's approach is to provide a step-by-step feature. The step-by-step feature is to break an animation into segments, each segment corresponding to a step. The purpose of these segments is to contain all the information required for a step, such as by way of example, an initial properties setup for all the objects. The objects are, by way of example and without limitation, position, size, opacity, visibility, and the like. Also, a series of animators for the objects will be used in the step.
Viewpoint Technology (VET) has provided a rudimentary process to accomplish a similar functionality as provided by the present invention, however, it has proven to be a drawback in a project's development cycle. Viewpoint's approach to provide a step-by-step feature is to break an animation into segments, each segment corresponding to a step. The purpose of these segments is to contain all the information required for a step:                (a) An initial properties setup for all the objects: position, size, opacity, visibility, etc.        (b) A series of animators for the objects that will be used in the step.        
FIG. 1 illustrates an overview of Viewpoint's approach to provide a step-by-step feature. First, the animation needs to be created by using a 3D authoring tool, such as by way of example, LightWave, Maya or 3D Max. Creating an animation by using a 3D authoring tool in a project is a standard technique, regardless of the final output format. The layout of the animation at this stage is a continuous timeline. Being a continuous timeline means that it has one starting and one ending point. The continuous timeline starts at zero and ends at the animation's length, (i.e., thirty seconds, five minutes, twelve minutes or one hour twenty minutes).
Using this layout, a breakdown needs to be done in order to produce the step-by-step version. The steps and their corresponding layouts for each step are identified. The layouts include information regarding each of the object's properties, such as, position, size, opacity, visibility, texture. Not all properties are required to be specified, only those appropriate for a specific step. In general, the position setup is always present, this is because objects (instrumentation, anatomical sections, etc.) change location throughout each step of the procedure, and by playing a particular step, an object's initial position for that step needs to be specified.
FIG. 2 illustrates an XML layout for a Viewpoint development in a four step project. The four step animation illustrated in FIG. 2 contains four different objects. Each step has its own set of animation segments, either for an object's initial setup or animation segment. Step 1 shows four positioning segments for objects 1-4, and one animation for object 1. Not all properties nor all objects are necessarily included as part of a step, as shown in step 2, where only object 1 and object 2 are affected; and object 3 and 4 are not. In addition, an object can have several animation segments: object 1 has two, in step 1 and step 2; object 3 also has two, in step 3 and in step 4.
Although the Viewpoint process provides a way to enable the step-by-step feature on animations, such a process is not an optimal solution. The impact the Viewpoint process has is not in the user's perspective, but in the development cycle for all projects. FIG. 2 only shows a simple example of a project, but it demonstrates that as complexity increases, the number of animation segments will increase dramatically.
The creation of each animation segment is done within a 3D authoring tool, and the time interval for a step needs to be identified and the start position and the end position for all tools and the animation sequences for the required objects are defined. Each step sequence has its own timeline, starting at zero and ending at the step's length. Once exported to the VET format, these sequences translate into XML code, creating code segments similar to the ones shown in FIGS. 17, 18 and 19. Where FIG. 17 illustrates code for an initial setup configuration for one object for step one; and FIG. 18 illustrates code for an initial setup configuration for one object for step two; and FIG. 19 illustrates animation code for one object during a particular step.
More particularly, FIG. 17 illustrates a section of XML code corresponding to object obj01 in step one. Its purpose is to assign an initial position and opacity to the object. Lines 4 and 5 are referencing the corresponding properties: “loc_” (location/position) and “opac” (opacity). The fact that the timeline, line 7, goes from 0 to 0.01 (it has a duration of 1/100 seconds), indicates that the object's properties are being initiated, since that interval is too short for anything to be visualized.
FIG. 18 is similar code to that illustrated in FIG. 17. For the code illustrated in FIG. 18 the object obj01 is being initiated (timeline runs from 0 to 0.01) with its position and visibility properties, but for step two.
FIG. 19 corresponds to code for an animation segment of object obj01 for step two. In the situation illustrated in FIG. 19, the animation is changing the values for the position property of the object. The associated transition occurs during the interval from 0 to 19 seconds (line 4). If several properties need to be modified during this interval, additional property targets need to be declared. These will be similar to the one at line 2; a segment block for that particular property will also need to be added (lines 6-8).
Potentially, a very complex project can have one setup segment for each object for each step. In addition, it will also have an animation segment for each object, for each step. This would create a series of code similar to the ones in FIGS. 17 and 18. As a consequence, the XML code is more extensive, creating larger files.
In Viewpoint's process as well as the known prior art, there is one animation sequence per object per step. The one animation sequence per object per step is for those objects which need to be animated and for initial placement in a step as illustrated in FIG. 2. The MAG10 object of the present invention only requires one animation sequence per object.
It is, therefore, a feature of the present invention is to allow viewers to jump to a specific point of the animation, in either direction. The development of an external object library (MAG10 object) to control an animation's timeline is disclosed. The present invention works in conjunction with animations created for media players generally, and specifically for the Viewpoint Media Player (VMP). The present invention provides an innovative set of features to enhance the user's interactivity with an animation. The primary function of the MAG10 object is to allow viewers to jump to a specific point of the animation, in either direction.
Additional features and advantages of the invention will be set forth in part in the description which follows, and in part will become apparent from the description, or may be learned by practice of the invention. The features and advantages of the invention may be realized by means of the combinations and steps particularly pointed out in the appended claims.